Program and device class entitlements in a media platform

ABSTRACT

A method and apparatus for managing entitlements in a broadcast stream are disclosed. The method includes identifying a program within a received media stream for a channel, receiving entitlements associated with the program, and writing an entitlement block containing the entitlements into a manifest file for delivery to a media client in the broadcast stream.

PRIORITY UNDER 35 U.S.C. §119(e) & 37 C.F.R. §1.78

This nonprovisional application claims priority based upon the followingprior United States provisional patent application(s): (i) “PROGRAM ANDDEVICE CLASS ENTITLEMENTS IN A MEDIA PLATFORM,” Application No.62/153,036, filed Apr. 27, 2015, in the name(s) of Daniel Biagini,Robert Arritt, Kevin Ma, Mikhail Mikhailov, and Prabhudev Navali; whichis hereby incorporated by reference in its entirety.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to communication networks. Moreparticularly, and not by way of any limitation, the present disclosureis directed to a system and method for providing program and deviceclass entitlements in a media platform configured for adaptive bitrate(ABR) media distribution and delivery in a network environment.

BACKGROUND

Content providers have long struggled with how to provide content at ahigh availability and high performance to their customers in view ofbandwidth limitations in content distribution networks. A ContentDelivery Network (CDN) can be a large distributed system of serversdeployed in multiple data centers connected to the Internet or otherpublic/private communication network. The goal of a CDN is to servemedia content (e.g., video/audio/etc.) to User Equipment nodes (UEs)with high availability and high performance. Example UEs that canreceive media content are set-top-boxes, television, multimediacomputers, and wireless terminals (e.g., smart phones and tabletcomputers).

The bandwidth requirements for distributing content from contentproviders to central CDN servers and/or to distributed Edge replicationservers have grown tremendously with the proliferation of adaptivestreaming content delivery solutions. Adaptive streaming technology isbeing implemented to handle increasing consumer demands for streamingcontent from Over The Top (OTT) applications on OTT content servers(e.g., broadcast and on demand movies/TV etc.) across one or more CDNsto UEs having widely differing performance and protocols. Exampleadaptive streaming technology that continues to be developed includesApple initiated HTTP Live Streaming (HLS) protocol, Microsoft initiatedSmooth Streaming (SS) over HTTP protocol, Adobe initiated DynamicStreaming protocol, and MPEG Dynamic Adaptive Streaming over HTTP (MPEGDASH) protocol, etc.

Adaptive streaming technology converts a source media content streaminto a plurality of content streams having different coding bit rates. Agroup of multiple bit rate content streams may be transcoded to providea plurality of groups of multiple bit rate content streams havingdifferent distribution container formats that can be required bydifferent streaming protocols used by UEs (e.g., HLS protocol, SmoothStreaming protocol, Dynamic Streaming protocol, MPEG DASH protocol,etc.). Accordingly, a single group of multiple bitrate content streamscan result in numerous groups of differently formatted multiple bit ratecontent streams that need to be distributed and stored at a central CDNserver and/or distributed to Edge replication servers to enable highavailability and high performance delivery to many different types ofUEs.

An example adaptive streaming server system may be configured to acceptmedia content from live sources and/or static file sources, e.g., onlinecontent providers such as Hulu®, Netflix®, YouTube®, or Amazon® Prime,etc. Media content from live sources may comprise live programmingcaptured relative to any type of event, e.g.,sporting/entertainment/gaming events, concerts, live TV shows, live newsbroadcasting, etc.

In the context of digital content delivery, such as OTT delivery ofvideo content, there are typically entitlements associated with a givencontent title, user, device, location, etc. Traditional contentprotection or Digital Rights Management (DRM) systems support a smallnumber of such entitlements, such as play count, expiration time andoutput controls, embedding these entitlements into licenses delivered toindividual clients. These schemes fall short and are unable to properlysupport modern online video services, which include not onlyVideo-On-Demand (VOD) but also live programming, with complex businessrules.

SUMMARY

The present patent disclosure is broadly directed to systems, methods,apparatuses, devices, and associated non-transitory computer-readablemedia for providing and effectuating program and device classentitlements in a media environment configured for, by way ofillustration, ABR media distribution and/or delivery in a networkenvironment as set forth in this and accompanying materials. Embodimentsset forth herein identify individual programs within a live channel andcan apply a wide range of entitlements not only to the parent channelbut also to each individual program within that channel. The rules foran individual program, if specified, take precedence over channel rules.Furthermore, while some entitlements depend on the particularuser/subscriber, there are also content-specific entitlements that applyto content in general and do not depend on the user. Thecontent-specific entitlements for a program can be delivered in thegeneric manifest available on the CDN, rather than fetched by the clientas part of the license, as in traditional DRM systems. The manifest maycontain a number of encrypted sets of entitlements, each targeted to aspecific class of client devices. Each client selects the set ofentitlements that matches the device on which the client is running.

A signal can be sent to the client when the client needs to takeuser/subscriber information into account when evaluating entitlements.In this case, the client can proactively fetch entitlements from the DRMserver by issuing an explicit request. Entitlements delivered directlyfrom the DRM server can either be combined with the entitlementsdelivered via the manifest or can provide stand-alone entitlements thatoverride all other provided entitlements. All entitlements are deliveredand used in a secure manner and cannot be tampered with by an attacker,either while in transit or while on the user device. The list ofentitlements supported in this manner is incomparably larger than thosesupported by traditional DRM systems and can include play count,activation time, expiration time, device type(phone/tablet/browser/STB), playback enabled/disabled on jailbrokendevices, network connection type (3g/4g/wifi), hdmi/airplayenabled/disabled, in/out home, in/out country, stream count limits,minimum bitrate, maximum bitrate, fast-forward enabled/disabled, rewindenabled/disabled, maximum bitrate on a jailbroken device,minimum/maximum play position, maximum number of ads to play, sessionshift enabled/disabled, etc. New entitlements can be added as necessaryor desired.

In one aspect, an embodiment of a method operable on a media platformfor providing program entitlements in a broadcast stream is disclosed.The claimed method comprises, inter alia, identifying a program within areceived media stream for a channel; receiving entitlements associatedwith the program; and writing an entitlement block containing theentitlements into a manifest file for delivery to a media client in thebroadcast stream.

In another aspect, an embodiment of a method operable on a mediaplatform for providing program entitlements in a broadcast stream isdisclosed. The claimed embodiment involves, inter alia, receivingchannel entitlements for a channel in the broadcast stream; receivingprogram entitlements for a program provided on the channel; providingthe channel entitlements to a media client responsive to a request forthe channel; and providing the program entitlements to the media clientprior to showing the program on the channel.

In another aspect, an embodiment of an apparatus for providing programentitlements in a broadcast stream is disclosed. The claimed embodimentcomprises, inter alia, one or more processors operably coupled to amemory having a sequence of program instructions which, when executed bythe one or more processors, perform the following: identifying a programwithin a received media stream for a channel; receiving entitlementsassociated with the program; and writing an entitlement block containingthe entitlements into a manifest file for delivery to a media client inthe broadcast stream of the channel. Further features of the variousembodiments are as claimed in the dependent claims.

Advantages of the present invention include, but are not limited to:

-   -   Digital rights can be applied not only to a streaming channel,        but also to specific programs within the channel;    -   No new communications are necessary to provide the rights,        providing a more scalable solution;    -   Different digital rights can be applied to different classes of        devices; and    -   A much broader variety of digital rights can be enforced using        the disclosed methods and devices.        Additional benefits and advantages of the embodiments will be        apparent in view of the following description and accompanying        Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present disclosure are illustrated by way of example,and not by way of limitation, in the Figures of the accompanyingdrawings in which like references indicate similar elements. It shouldbe noted that different references to “an” or “one” embodiment in thisdisclosure are not necessarily to the same embodiment, and suchreferences may mean at least one. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it is submitted that it is within the knowledge of oneskilled in the art to effect such feature, structure, or characteristicin connection with other embodiments whether or not explicitlydescribed.

The accompanying drawings are incorporated into and form a part of thespecification to illustrate one or more exemplary embodiments of thepresent disclosure. Various advantages and features of the disclosurewill be understood from the following Detailed Description taken inconnection with the appended claims and with reference to the attacheddrawing Figures in which:

FIG. 1 depicts an embodiment of a media environment wherein anembodiment of the present invention may be practiced;

FIG. 2 depicts a block diagram of a client device wherein an embodimentof the present invention may be practiced;

FIG. 3 depicts the data flow between components of the media environmentaccording to an embodiment of the present patent application;

FIG. 4 depicts communications between various components of the mediaenvironment according to an embodiment of the present patentapplication;

FIGS. 5A-5C depict an illustrative method for providing program anddevice class entitlements to a media client according to an embodimentof the present patent application;

FIGS. 6A-6B depict an illustrative method for providing program anddevice class entitlements to a media client according to an embodimentof the present patent application;

FIG. 7A depicts an illustrative method for enforcing entitlements at amedia client according to an embodiment of the present patentapplication;

FIGS. 7B-7E depict additional aspects that can be practiced incombination with the method of FIG. 7A according to an embodiment of thepresent patent application;

FIG. 8A depicts an illustrative method for enforcing entitlements at amedia client according to an embodiment of the present patentapplication;

FIGS. 8B-8D depict additional aspects that can be practiced incombination with the method of FIG. 8A according to an embodiment of thepresent patent application;

FIG. 9 depicts a block diagram of an example network node in theimplementation of FIG. 1 according to an embodiment of the presentpatent application;

FIG. 10 depicts a block diagram of an example set top box according toan embodiment of the present patent application; and

FIG. 11 depicts a block diagram of an example mobile device or wirelessUE device according to an embodiment of the present patent application.

DETAILED DESCRIPTION OF THE DRAWINGS

In the following description, numerous specific details are set forthwith respect to one or more embodiments of the present patentdisclosure. However, it should be understood that one or moreembodiments may be practiced without such specific details. In otherinstances, well-known circuits, subsystems, components, structures andtechniques have not been shown in detail in order not to obscure theunderstanding of the example embodiments. Accordingly, it will beappreciated by one skilled in the art that the embodiments of thepresent disclosure may be practiced without such specific components. Itshould be further recognized that those of ordinary skill in the art,with the aid of the Detailed Description set forth herein and takingreference to the accompanying drawings, will be able to make and use oneor more embodiments without undue experimentation.

Additionally, terms such as “coupled” and “connected,” along with theirderivatives, may be used in the following description, claims, or both.It should be understood that these terms are not necessarily intended assynonyms for each other. “Coupled” may be used to indicate that two ormore elements, which may or may not be in direct physical or electricalcontact with each other, co-operate or interact with each other.“Connected” may be used to indicate the establishment of communication,i.e., a communicative relationship, between two or more elements thatare coupled with each other. Further, in one or more example embodimentsset forth herein, generally speaking, an element, component or modulemay be configured to perform a function if the element is capable ofperforming or otherwise structurally arranged to perform that function.

As used herein, a network element or node may be comprised of one ormore pieces of service network equipment, including hardware andsoftware that communicatively interconnects other equipment on a network(e.g., other network elements, end stations, etc.), and is adapted tohost one or more applications or services with respect to one or moresubscribers. As such, some network elements may be disposed in awireless/wireline telecommunications network or a cable provider networkwhereas other network elements may be disposed in a publicpacket-switched network infrastructure (e.g., the Internet or worldwideweb, also sometimes referred to as the Cloud), private packet-switchednetwork infrastructures such as Intranets and enterprise networks, aswell as service provider network infrastructures, any of which may spanor involve a variety of access networks and core networks in ahierarchical arrangement. Where digital content or assets are consumedby the subscribers, network elements hosting such digital content orassets may be disposed in suitable CDN infrastructures. Accordingly,some network elements may comprise “multiple services network elements”that provide support for multiple network-based functions.

In general, the terms “content” or “content file” as used in referenceto at least some embodiments of the present patent disclosure mayinclude digital assets and program assets such as any type ofaudio/video (NV) content or program segment, live streaming or static(e.g., recorded over-the-air free network TV shows or programs, pay TVbroadcast programs via cable networks or satellite networks, free-to-airsatellite TV shows, IPTV programs, etc.), OTT and VOD or Movie-on-Demand(MOD) shows or programs, time-shifted TV (TSTV) content, locally storedcontent or network-stored content, as well as other content assetsprovided by content publishers, owners or providers, including but notlimited to software files, executable computer code or programs, onlineelectronic games, Internet radio shows/programs, entertainment programs,educational programs, movies, music video programs, and the like.Further, the content may be delivered, received or provided to the UEdevices using broadcast cable TV, local TV, switched digital video (SDV)TV, satellite TV, broadband Internet, via one or more ABR streamingtechnologies. Example subscriber end stations or client devices maycomprise any device configured to execute, inter alia, a streamingclient application (e.g., an ABR streaming client application) forreceiving content from one or more content providers, e.g., via abroadband access network. Such client devices may therefore includeset-top boxes (STBs) with or without integrated cable cards, TVs,personal/digital video recorders (PVR/DVRs), networked media projectors,portable laptops, netbooks, palm tops, tablets, smartphones, videophones, mobile/wireless user equipment, portable media players, portablegaming systems or consoles (such as the Wii®, Play Station 3®, etc.) andthe like that may access or consume content/services provided via asuitable dynamic packager network architecture for purposes of one ormore embodiments set forth herein.

One or more embodiments of the present patent disclosure may beimplemented using different combinations of software, firmware, and/orhardware. Thus, one or more of the techniques shown in the Figures(e.g., flowcharts) may be implemented using code and data stored andexecuted on one or more electronic devices or nodes (e.g., a subscriberclient device or end station, a network element, etc.). Such electronicdevices may store and communicate (internally and/or with otherelectronic devices over a network) code and data using computer-readablemedia, such as non-transitory computer-readable storage media (e.g.,magnetic disks, optical disks, random access memory, read-only memory,flash memory devices, phase-change memory, etc.), transitorycomputer-readable transmission media (e.g., electrical, optical,acoustical or other form of propagated signals—such as carrier waves,infrared signals, digital signals), etc. In addition, such networkelements may typically include a set of one or more processors coupledto one or more other components, such as one or more storage devices(e.g., non-transitory machine-readable storage media) as well as storagedatabase(s), user input/output devices (e.g., a keyboard, a touchscreen, a pointing device, and/or a display), and network connectionsfor effectuating signaling and/or bearer media transmission. Thecoupling of the set of processors and other components may be typicallythrough one or more buses and bridges (also termed as bus controllers),arranged in any known (e.g., symmetric/shared multiprocessing) orheretofore unknown architectures. Thus, the storage device or componentof a given electronic device or network element may be configured tostore code and/or data for execution on one or more processors of thatelement, node or electronic device for purposes of implementing one ormore techniques of the present disclosure.

Turning to the figures now, FIG. 1 depicts an embodiment of a mediaenvironment 100 wherein the present invention may be practiced. Mediaplatform 101 sits logically between a service provider's back office andclient devices 103, and provides live streaming media to client device103 through CDNs such as CDN 106. In media environment 100, the serviceprovider's back office includes Content Management System (CMS) 108,Subscriber Management Systems (SMS) 114 and Customer Care system 118.CMS 108 manages the acquisition of content and provides bookkeeping ofdigital assets and associated business rules and service profiles. SMS114 receives and stores all subscriber-related information and, inconjunction with a billing system, is the arbiter of which subscribershave access to specific elements of content. Customer Care system 118provides billing and revenue management. Each of these back officeservers provides information that is critical to the real-timeprovisioning of streaming media to customers, but none have a presencein the video session setup path. Therefore, these servers are not awareof device authentication and runtime analytics, such as usage and actualdevice profile for client device 103, to effectively enforceentitlements. Media platform 101 provides integration of CMS, SMS andCustomer Care functions into the authentication pathway for clientdevices and the delivery of live streaming media to those clientsthrough Content Server (CS) 110, Entitlement Director (ED) 116, andAnalytics Report Generator (ARG) respectively. Each of CS 110, ED 116and ARG 120 communicates with its respective back office functionalityand also communicates with either Media Manager (MM) 112A or ContentController (CC) 122. Media Manager 112A and its backup, MM 112B, act asan administrator to receive electronic programming data and subscriberinformation and authenticates user access based on correlating device,user and content rights. Content Controller 122 is a DRM license serverthat interacts with client devices to support content delivery based onclient requests and service mediation. In at least one embodiment, anexternal rights server can push rights information to MM 112. In atleast one embodiment, CC 122 can perform call outs to an external rightsserver in order to provide entitlements in response to client requests.

Media platform 101 also receives incoming media 130 for each providedchannel from a content provider 102, which may provide both stored VODand live media. Within media platform 101, one or more preparationprocessors (PP) 104 act on the incoming media 130. PP 104 can transcode(132) the media into multiple bitrates to support ABR delivery wherenecessary, segment (134) the media for transport, and encrypt (136) andupload (138) the segmented media for delivery to CDN 106 as processedmedia 140 that is ready for distribution on one or more channels of livestreaming media. At the appropriate time, CDN 106 streams the processedmedia to requesting client device 103. The final piece of mediaenvironment 100 is client device(s) 103. Although only one client deviceis shown in this example, it will be understood that CC 122 interactswith numerous client devices. The traditional client device forstreaming media has been the STB for in-home television viewing.However, as customers increasingly demand access to available content onmobile devices, client device 103 now includes unmanaged devices such aslaptops, smartphones, tablets, smart TVs, game consoles and DVD players.Since these devices are not preregistered or preconfigured to receivesubscribed services, service delivery to client device 103 must bedynamically detected, authenticated and controlled on demand based ontheir entitlement. Client device 103 typically contains a media client124, which interacts with CC 122, as well as media player 126, which maybe provided as part of the operating system of the client device.

In at least one embodiment, media platform 101 is configured to supportprogram entitlements for use during certain VOD playback modes (e.g.,catch-up & network PVR (nPVR)) only. In at least one embodiment, mediaplatform 101 is configured to provide support for media program basedentitlements applied during live, e.g., linear, playback mode. Liveprogram entitlements may be used to enforce playback business rules,which are required for compliance of content rights agreements. In atleast one embodiment, program entitlements can be signaled to MC 124 foreach program occurrence on the linear stream. In at least oneembodiment, MC 124 is configured to dynamically update the currententitlement rule-set upon the start of the corresponding program and totrigger enforcement using the updated rules. In at least one embodiment,restrictions such as out-of-home playback are supported on a per programbasis.

FIG. 2 provides a simplified block diagram of a client device 200, suchas client device 103, showing the components involved in receipt andplayback of streaming media, specifically Service Provider Application202, Media Client (MC) 220 and Media Player 242. SP Application 202provides communication with a user through User Interface 204, whichsupports login of the user and provides programming information to theuser. In at least one embodiment SP Application 202 pairs itself with anSTB; SP Application 202 can then determine whether client device 200 isin-home or -out-of-home and provide that information to MC 220. TheService Provider Application 202 also contains PVR Controls 206, EPGDiscovery 208, Ad Delivery 210 and Portal Interface 212. Media client220, which is one embodiment of media client 124, manages authenticationof client device 200 with media platform 101, retrieves content, playsthe content on media player 242, and provides local enforcement of DRMthrough its connection to media player 242, which is part of theoperating system (OS) 240 of the client device 200. Media client 220also contains modules to perform Device Management 222, EntitlementEnforcement 224, Analytics 226, Ad Insertion 228, CDN Selection 230 andBandwidth Management 232. ABR Manifest File Control 234 receives themanifest file that is provided for a requested channel and is able tocoordinate changes in the requested bitrate for streaming. TransparentData Proxy 236 provides connection between MC 220 and the Internet andABR/DRM 238 communicates with CC 122 for authentication, exchangeschannel information (including entitlements associated with the channel)and subscriber information with CC 122, and when a subscriber overrideis in effect, requests entitlements for each program from CC 122.

MC 220 can apply at least the following example program entitlementsdynamically at program boundaries; in at least one embodiment, theseentitlements can be based on device classification:

-   -   Supported device types, e.g., phone, tablet, browser;    -   Jail broken disabled (jail breaking is a privilege escalation        process of removing system restrictions e.g., hardware,        firmware, etc. on a device OS, e.g., iOS, which permits root        access to the OS file system and manager, allowing download of        additional applications, extensions, etc. that may be        unofficial);    -   Network connection type (e.g., 3G/4G, Wifi);    -   HDMI/Airplay disabled; and    -   Playback enabled/disabled.

Additional entitlements, which can't be detected within MC 220, can bedetected and/or enforced in CC 122. In at least one embodiment, MC 220is configured for this purposes to utilize a beaconing mechanism, i.e.,keep-alive messaging that regularly exchanges information with CC 122regarding, e.g., content consumption, user overrides, etc. In at leastone embodiment, these entitlements can include at least:

-   -   Stream count limits;    -   In/Out home; and    -   In/Out country. In at least one embodiment this entitlement is        implemented via a rights callout to an external system.

In at least one embodiment, a set of entitlements uses a 5-tuple thatincludes primary (a.k.a. account), user_token, device_id, media UniqueIdentification Number (UID) and media group to determine whichentitlement properties or rights are applied to a given playbackrequest. In at least one embodiment, an additional entitlement targetingmechanism is provided to allow more granular application of programentitlements on specific types of devices, as well as the potential toapply other types of entitlements. This mechanism is similar to an MPDevice Class object, which allows classification based on at least thefollowing device attributes:

-   -   OS, e.g., iOS, Android, Browsers, Win Phone;    -   OS version, which can include compound version comparisons;    -   Manufacturer; and    -   Model.        In at least one embodiment, device classification is a string        matching qualifier with wildcard support that the MC 124 and/or        CC 122 uses to determine whether a given rule applies to a        target user device.

There can be instances where it is desirable for the entitlements of aspecific subscriber, e.g., a combination of primary, user and device, tooverride the content entitlements of a program. In at least oneembodiment, a mechanism is provided to force MC 124 to query CC 122 forentitlement updates on a per program basis. In at least one embodiment,MC 124 does not wait until the moment right before or after a programchange occurs to callout to CC 122 for an entitlements update.

In at least one embodiment of the disclosure, content owners canrestrict certain content from being played from outside the home.In-home-only playback can be controlled by at least the following twomechanisms:

-   -   Matching the source IP address of client messages against a        known home gateway IP address in the CC; and    -   Application controlled STB pairing as means of in-home        detection.

Scalability of signaling for content program entitlements can beaccomplished by limiting the amount of communication between MC 124 andCC 122 required for entitlements messaging. Embedding the entitlements,as well as any associated device classifiers, within the video stream,e.g., inline, in-band, or in-stream signaling, may advantageouslyprovide the signaling of content entitlements without any additionalMC-CC interactions. Preparation processor video processing outputs amanifest file which contains stream metadata. According to thisdisclosure, the manifest file is configured to deliver contententitlement and device classifying data to clients with minimal overheadon CC 122. In at least one embodiment, the manifest file is alsoutilized to signal many value-added features, e.g. ad-insertion,parental controls, timeshifting features, etc. In at least oneembodiment, manifests are provided in HLS m3u8 format; in at least oneembodiment the manifest entitlement signaling approach is provided inMPEG DASH mpd files or extended to other manifest types.

FIG. 3 depicts an embodiment of the data flow between components of themedia environment for program entitlement delivery. Media Manager 112,Content Controller 122 and Preparation Processor 104 are each part ofmedia platform 101, which is connected to both CDN 106 and Media Client124. An external EPG data source 302 pushes program data and entitlementinformation into Media Manager 112 via a media/program ApplicationProgramming Interface (API) 310. A program scheduler (not specificallyshown), which may be operating at or otherwise associated with MM 112,is responsible for provisioning the next program at PP 104. It should beappreciated that a network node/functionality may be configured as arecorder, transcoder and uploader (RTU) (not specifically shown)associated with PP node 104 that is operative to fetch original contentfile from a remote system, transcode it into various bitratesappropriate for the target client platforms, and then upload transcodedand segmented files to a Content Distribution Network 304 or OriginServer. The program scheduler can retrieve the correspondingentitlements, based on program media UID & program's media groups, andpass an entitlements “block” to the RTU via a ProgramInfo message overcommunication link 312. This may occur for both Timeshift enabledchannels (“out-of-band” segmentation) and legacy live streams.

The RTU functionality passes the ProgramInfo message to a segmenterprocess (not specifically shown), which may be operating at or otherwiseassociated with PP 104. The segmenter may be configured to write theentitlements into the manifest file. If the channel is running inprogram segmentation mode then the entitlements block may be placed atthe top of the manifest file. If the channel is in sliding window modethe entitlements may be placed at the top of the file and after anyprogram boundary indicators, including the program media UID, start/endtimes, and any program parental control rating that was passed. Themanifest file and video content is then sent to CDN 106 overcommunication link 314. MC 124 performs a playback request using asuitable “client/roll” API, shown as communication link 320. The DRMobject that is returned from CC 122 contains the entitlements for theparent channel. The object may also contain an additional override flagto support subscriber_check, a subscriber override option. In at leastone embodiment, MC 124 is configured to retrieve entitlements for thenext program via a DRM token retrieval API or a beacon API. In at leastone embodiment, various MCs are configured to spread the next programentitlement lookup over different beacons to help spread the load outover the full program duration.

For program entitlement signaling, if subscriber_check is false or notavailable, MC 124 parses ProgramInfo comments from the manifest file,and iterates through the entitlement objects, choosing the first objectwhose Device Class matches the local platform attributes. Ifsubscriber_check is true, MC 220 calls client/token retrieval toretrieve the entitlements for the next program, preferably before theend_time of the current program. End_time and next program UID can bothbe found in the PROGRAM-INFO tag of the bitrate manifest files. The DRMtoken retrieval API call, shown as communication link 322, may containthe media UID of the next program in order to retrieve the full set ofentitlements for that next program. In at least one embodiment, thetoken retrieval API is configured to perform a subscriber/contententitlement merge for that program and return a single DRM Object withthe corresponding rights and the first encryption key for the program.If key rotation is disabled, the key may be the same.

In at least one embodiment, the RTU and segmenter adds the necessaryProgram-Info tag, including entitlements, to the manifest files when thePreparation Processor node 104 is operating in either packager ortranscoder mode. Similar manifest entitlement support can also be addedto a Just-In-Time Packager (JITP) manifest processing to allow forintegrated Playback Business Rules (PBR) with suitable PP or packagingimplementations.

In at least one embodiment, the top of the manifest containsPROGRAM-INFO tags for 3 programs: previous, current and next. EachPROGRAM-INFO can include at least the following information:

-   -   Program ID (PID);    -   Program Name;    -   Start Time in Coordinated Universal Time (UTC);    -   Duration;    -   Media UID (MUID); and    -   Entitlement Block.

The PROGRAM-INFO tag can include an Entitlement block:ENTITLE=“<entitlement-block>”, and also a signature hash to allow forquick change detection of the block: ENTITLE_HASH=“<signature>”. Bothvalues may be set to “−1” to signal no entitlements for a program. Themanifest file is protected by manifest cryptographic signing andverification workflow. MC 124 parses through the objects for the nextprogram and select the first object which matches the local devicecharacteristics.

In at least one embodiment, the entitlements block includes multipleentitlement objects, each with an optional Device Class (DC) Target.Each entitlement with an association to the program, either directly orvia media group, can be merged using an exemplary entitlement rulesprecedence engine, e.g., wherein a lower priority numerical valueindicates a higher rule precedence. In at least one embodiment,different DC targets do not merge into a single entitlement; insteadeach distinct DC target carries a merged entitlement set for the target.In at least one embodiment, multiple sets of merged entitlements fordifferent DC targets are combined to form the entitlements block.Maintaining an existing DRM token object format can allow MC 124 toreuse existing parsing and handling code.

In at least one embodiment, the combined Device Class and Entitlementobject string has the following form:

-   -   <device-class>::<entitlement-object>        The below example illustrates the use-case of a program (Prog1)        being blocked on all Android phone devices, and a second program        (Prog2) being blocked on all Android phones and Android tablets        of a particular manufacturer. Both Prog1 and Prog2 belong to a        MediaGroup, MG1. The example assumes that Device Classes “DC1”        and “DC2” have the following definitions:

Device Class: DC1

-   -   OS: Android    -   Version: *    -   Manufacturer: *    -   Model:

Device Class: DC2

-   -   OS: Android    -   Version: *    -   Manufacturer: Samsung    -   Model: Galaxy*

TABLE 1 Media Rights Example Media Media Device Phone Tablet Desktop UIDGroup Class blocked blocked blocked Priority Prog1 DC1 T F F 20 Prog2DC1 T F F 20 Prog2 DC2 T T F 20 MG1 F F F 100

The corresponding entitlement block for Prog1 may contain the followingtwo Entitlement Objects, the first for DC1 and the second having a NULLDC (wildcard, applies to all):

Prog1 Entitlement Block

-   -   <DC1>::1#0#0    -   ::0#0#0        Similarly, the Prog2 block contains three Entitlement objects:

Prog2 Entitlement Block

-   -   <DC1>::1#0#0    -   <DC2>::1#1#0    -   ::0#0#0        It should be appreciated that the Entitlement Object encoding in        the above example is shortened for simplicity to only the 3        specified binary values; the actual encoding may be much longer,        may contain the full object values, and are always encrypted.        <DC1> and <DC2> are placeholders for the Device Class        definitions, as set forth below.

MC 124 is responsible for parsing the encoded Device Class definitionsof each Entitlement Object within the Entitlement Block until a match isfound. In at least one embodiment, the first matching object in theblock is chosen to provide the new set of entitlements to apply startingat the specified start time in the Program Info of the manifest file. Ifa signature hash is utilized, MC 124 is operable to determine whetherthe hash value for the next program is the same as the hash value forthe current program. If the two values are equal, there is no changebetween the two sets of entitlements. In this embodiment, MC 124 isoperable to skip parsing of the Entitlement Block and to apply theentitlements for the current program to the next program. In at leastone embodiment, specific browsers and/or operating systems may betargeted using different targeting mechanisms.

In at least one embodiment, Device Class encoding is in the form:

-   -   <DC-version>:<OS string>:<Version match range>:<Manufacturer        string>:<Model string>        The DC-version may be a constant ‘1’ on an example        implementation. Each string component of the class, e.g., OS,        Manufacturer and Model, can be used in a case insensitive or        case sensitive comparison to the local device attributes. In at        least one embodiment, a wildcard match for the end of a string        is specified using an asterisk (“*”) in the class component. In        at least one embodiment, the string is required to be an exact        match up, until the optional wildcard character, to the value        returned by the client platform for a class to qualify as a        match. A <Version match range> component allows two forms:    -   Exact match—if the supplied <version match range> string doesn't        contain a ‘>’ or ‘<’ character then the string is matched to the        exact version returned by the appropriate platform; and    -   GT/LT/GTE/LTE match—if the supplied <version match range> string        contains a ‘>’ or ‘<’ value, the supplied version is to be        compared to the platform version using the appropriate numerical        comparison operator.

A subscriber override of content entitlements can be signaled by aproperty or parameter called, e.g., subscriber_check in a DRM RightsObject that is returned from the response to the client/roll APImentioned previously. In at least one embodiment when set, MC 124 canignore the program entitlements contained within the manifestEntitlement Blocks. In at least one embodiment, MC 124 periodicallyutilizes an API to CC 122 to retrieve the computed entitlements for eachprogram. The CC API call can be done at a random time before the startof the next program in order to amortize the load on CC 122 over thefull time span of the current program.

When subscriber_check is false, MC 124 and the related DRM Agent 238 maynot make any additional rights object updates for that session, otherthan the potential updates signaled through the manifest. In at leastone embodiment, DRM Agent 238 can use the entitlements for the channelas a fallback object if there is an error in the program entitlementfrom the manifest. In at least one embodiment, when subscriber_check istrue, MC 124 refreshes rights via a token retrieval API call before eachprogram boundary. This call may use a program_media_uid query stringparameter to specify the program's media_uid.

In at least one embodiment, media platform 101 and media client 124 areconfigured to support an application such as in/out home detection inorder to enforce in-home-only playback restrictions. FIG. 4 depicts anexample architecture for facilitating in-home-only playbackrestrictions, wherein appropriate steps/blocks/acts may take place toeffectuate the applicable restrictions. In at least one embodiment, anentitlement parameter or variable out_of home_blocked is used totransmit this feature. The out_of home_blocked entitlement can beapplied to targets similar to or compatible with an existing suite ofentitlement properties. Operators can use the media/rights API to setthis entitlement or use rights callout to return the property. In atleast one embodiment, MC 124 handles out_of home_blocked propertychanges on a per program basis, signaled either through the manifest,via communication link 416, or via the subscriber override mechanism,signaled via communication link 410. MC 124 can signal SP Application202 when out_of home_blocked is true to enable SP Application 202 toprovide in/out home detection. This signal is shown in the figure ascommunication link 412. In at least one embodiment, SP Application 202use an API called setHomeStatus( ) shown as communication 414, to signalwhether the client is in or out of home, allowing MC 124 and DRM Agent238 to restrict or allow playback as appropriate. In at least oneembodiment, MC 124 is configured to treat SP Application 202 as in-home,i.e., fail open, in the default state.

In at least one embodiment, a media/rights API is configured to supportdevice class targeting features set forth herein, as well as supportingdesired additional entitlements. In at least one embodiment, themedia/rights API is provided with the following signature, including oneor more new parameters:

-   -   POST http://hostname:2010/media/rights?owner_uid=uid        -   [&user_token=token[&device_id=id]|&primary=acct_group]        -   [&media_uid=uid|&media_group=name][&device_class_name=device_class]            where:    -   owner_uid Unique string that identifies the owner of the media        and/or the owner associated with the client.    -   user_token (Optional) Opaque token (sequence of characters) that        uniquely identifies a given user. In practice, the user token        could be a user name chosen by the user when the user creates an        account with the SMS, or a token (such as a cookie) generated by        the SMS when the user logs in.    -   device_id (Optional) Unique string that identifies the client        device to which the client rights apply.    -   primary (Optional) Primary client account group to which the        client rights    -   apply.media_uid (Optional) Unique string that identifies the        media to which the client rights apply.    -   media_group (Optional) Name of a media group to which the client        rights apply.    -   device_class (Optional) Name of a Device Class that may be used        as an additional device targeting qualifier to which the rights        may apply. More information on Device Class can be found herein.        In at least one embodiment, device_class is supported only for        “Content Rights”, i.e., rights which don't have any subscriber        targets specified.

In at least one embodiment, the following payload XML fields areconfigured to support new entitlements:

Field Description

-   out_of_home_blocked (Optional) [true|false|unspecified] User ability    to playback content when out of the home. Out of home status is    determined via the client application, and set via MC API.-   subscriber_check (Optional)) [true|false|unspecified] Rights    calculation and check may be performed for every program on a linear    channel. This allows for subscriber based override of Content Rights    on a per program/schedule basis.

CC Rights callout payload response parsing can be configured to handlethe inclusion of the additional rights properties such as, e.g.,out_of_home_blocked and subscriber_check, as set forth hereinabove. Inat least one embodiment, a CC DRM token retrieval API is used by MC 124to retrieve media DRM tokens. In at least one embodiment, a request fromMC 124 to CC 122 can be generated to retrieve media meta informationalong with entitlements and content decryption key, which can bereferred to as a roll request. In at least one embodiment, the responsefrom CC 122 is in XML, containing various pieces of informationdescribing for MC 124 where to find media segments, what bitrates areavailable, etc. In at least one embodiment, entitlements and/or acontent decryption key are contained in the encrypted DRM token returnedin one of the XML tags. The applicable API signature can be modified tosupport retrieval of program based entitlements for the“subscriber_check=true” case.

-   -   POST http://hostname:2010/client/rollite?owner_uid=uid        -   &media_uid=uid            &seq=key_sequence[&program_media_uid=program_uid]        -   [&primary=accountId]            where:    -   owner_uid Unique string that identifies the owner of the media        and the owner associated with the client.    -   media_uid Unique media UID that identifies the media (in the        case of live playback with subscriber_check mode, this may be        the media_uid for the channel).    -   seq Key sequence id    -   program_media_uid (Optional) Unique media UID of a program        instance on a channel for which the rights may be calculated.    -   primary (Optional) Account identifier (aka, client account group        id, primary account group id, account id).

FIGS. 5A-5C depict a series of flowcharts of an illustrative method at anetwork node for providing program and device class entitlements to amedia client according to an embodiment of the present patentapplication. Flowchart 500A begins with a network node identifying (502)a program within a received media stream for a channel. The node alsoreceives (504) the entitlements associated with the program. As notedabove, the entitlements can be received from a media source, e.g., atthe time the media is received. Finally, the node writes (506) anentitlement block containing the entitlements into a manifest file fordelivery to a media client in the live broadcast stream. In at least oneembodiment, it may not be necessary or desirable to provide programentitlements for each program on a channel. In this case, entitlementsassociated with the channel are provided as shown in flowchart 500B.This aspect of the method includes receiving (512) entitlementsassociated with the channel and providing (514) the channel entitlementsto a media client in response to receiving a playback request for thechannel from the media client. In this manner, when a program'sentitlements are missing or otherwise not available, the client is ableto utilize the channel entitlements to enforce entitlements for theprogram.

If a subscriber_check or subscriber override function is provided, themethod continues in flowchart 500C. The network node provides (522) asubscriber override indicator to a media client, e.g., thesubscriber_check indicator provided with the channel manifest duringcommunications between MC 124 and CC 122. The network node thendetermines (524) whether an override entitlement request for a nextprogram has been received from MC 220. If not, the node continues towait on a request. If a subscriber override request has been received,the network node then provides (526) the media client with overrideentitlements that are specific to the program and the media client.

FIGS. 6A-6B depict another series of flowcharts of an illustrativemethod at a network node for providing program entitlements to a mediaclient according to an embodiment of the present patent application. Inflowchart 600A, a network node receives (602) channel entitlements for achannel in the broadcast stream. These channel entitlements provideentitlements that apply to all programs on the channel. The network nodealso receives (604) program entitlements for a program provided on thechannel, e.g., by writing one or more entitlements into a manifest file.The network node can receive these program entitlements for as many oras few programs as desired. Program entitlements, if provided, willoverride the channel entitlements. The network node then ensures thatthe channel entitlements are provided (606) to a media client responsiveto a request for the channel. In at least one embodiment, the channelentitlements are sent to CC 122, which can provide the channelentitlements to MC 124 when a request to join a channel is received. Thenode also ensures that program entitlements are provided (608) to themedia client prior to showing the program on the channel. In at leastone embodiment, the entitlement block is included in a manifest that issent to CDN 106. CDN 106 then provides the manifest and media to mediaclient 124 at an appropriate time.

The ability to override the program manifest can be provided as shown inflowchart 600B. The network node, such as CC 122, provides (612) asubscriber override indicator to the media client, such as media client124. In at least one embodiment, the subscriber override indicator isprovided to the media client when a new session begins, e.g., at thetime a channel is requested. Alternatively, in one embodiment, thesubscriber override indicator is provided in a beaconing messagebetween, e.g., CC 122 and MC 124. The network node then waits todetermine (614) whether an override entitlement request for a nextprogram has been received from a media client. If not, the network nodecontinues to wait, but if an override entitlement request has beenreceived, the network node provides (616) the media client with overrideentitlements that are specific to the subscriber and the program.

FIG. 7A depicts flowchart 700A, which is directed to a method operatingon a user device for enforcing program entitlements in a broadcaststream. A media client, such as media client 124, receives (702) amanifest for a program in the live broadcast stream; the manifestproviding a program entitlement block. The media client then uses (706)the entitlements specified in the program entitlement block to enforceentitlements for the program.

FIGS. 7B-7E depict flowcharts 700B-700E of additional aspects of themethod that may be practiced in combination with the method of FIG. 7A.The disclosure has noted that along with the program entitlements, themedia platform can also provide channel entitlements that providedefault entitlement values and override entitlements that can supersedethe program entitlements, as well as using device class entitlements toprovide multiple entitlement objects in the manifest. While it can bebeneficial to practice all of these elements in a single embodiment, itis not necessary to do so. Accordingly, the process in the media clientmay proceed along several paths in dependence on which elements areincluded in any embodiment. Flowchart 700B deals with the use of asubscriber override. If this option is utilized in a system, mediaclient 124 will receive (710) the indicator in a message from CC 122,e.g., when a channel is requested. When the media client receives a newmanifest, e.g., in block 702, the media client will determine (712)whether the subscriber override is in effect, e.g., whether the value ofthe indicator is “True”. If the subscriber override is not in effect,the method can move to either block 706 or block 722, depending on theoptions used. If the subscriber override is in effect, the media clientsends (714) an override entitlement request to a content controller nodeor other network node performing this function. The media client willreceive (716) override entitlements and will use (718) the overrideentitlements to enforce entitlements for the program.

Flowchart 700C provides for the use of channel entitlements, such thatnot every program manifest needs to contain a program entitlement block.As will be understood, portions of flowchart 700C logically precedesflowchart 700A. Media client receives (720) channel entitlements for thechannel in which the program is broadcast. The channel entitlements canbe received, e.g., during communications with CC 122 when the channel isrequested. The media client then receives (722) a manifest containingnew program information. The media client determines (724) whether themanifest file contains a program entitlement block. If the manifest filedoes contain a program entitlement block, the flow moves to either block702 or block 732, depending on options. If the manifest file does notcontain a program entitlement block, the media client uses (726) theentitlements specified in the channel entitlement block to enforcedigital rights for the program.

Flowchart 700D provides for the use of device class entitlements, wheremultiple entitlement objects are provided in the program entitlementblock, and can be entered from either block 702 or block 724. The mediaclient determines whether the program entitlement block contains (732)multiple entitlement objects. If multiple entitlement objects are notpresent, the method moves to block 706. If multiple entitlement objectsare present, the media client selects (734) a first entitlement objectthat has a device class that matches the user device. The media clientthen uses (736) entitlements that are specified in the selectedentitlement object to enforce entitlements for the program.

Flowchart 700E is directed to the use of a hash code with the programentitlement block, which provides a method to streamline the process ofimplementing entitlements, by determining whether the programentitlement block has changed from the previous program. Where a hashcode is implemented, the content of each program entitlement block isused to create a respective hash code, which is transmitted with theprogram entitlement block. As noted previously, all entitlements areencrypted when they are received by the media client to prevent userabuse of digital rights, so if it is determined that two hash codes areidentical, there is no need to decrypt the entitlement block or tosearch for a matching device class. This flow chart is entered afterblock 724 after an entitlement block for a second program has beenreceived. The media client determines (742) whether the hash code of thenew program, which will be the next program to play, matches the hashcode of the current program. If the hash codes do not match, the mediaclient will move to one of blocks 706 or 732. If the hash codes domatch, the media client uses (746) the entitlements specified in thecurrent entitlement block to enforce entitlements for the new program.

FIG. 8A depicts flowchart 800A, which is directed to a method operatingon a user device for enforcing program entitlement in a broadcaststream. In this method, the media client receives (802) channelentitlements for a requested channel in the broadcast stream. Thechannel entitlements can be received, e.g., at the time the channel isrequested from the content controller node. The media client alsoreceives (812) program information for a program on the channel, e.g.,in the manifest. When a new program starts or will soon start, the mediaclient determines (804) whether a program entitlement block is providedfor the new program. If a program entitlement block is provided, themedia client uses (806) the entitlements specified in the programentitlement block to enforce entitlements for the program. If a programentitlement block is not provided, the media client uses (808) thechannel entitlements to enforce entitlements for the program.

FIGS. 8B-8D depict flowcharts of additional aspects of the method thatmay be practiced in combination with the method of FIG. 8A. Flowchart800B is directed to the use of a hash code with the program entitlementblock. The flowchart can be entered when the answer to block 804 is“yes”. The media client receives (810) a program entitlement block for anew program. The media client determines (812) whether the new hash codematches the current hash code. If the hash codes do not match, the mediaclient can proceed to either block 806 or block 820, depending on theoptions used. If the hash codes match, so will the contents of theentitlement blocks. Therefore, the media client can use (814) theentitlements specified for the current program to enforce entitlementsfor the new program.

Flowchart 800C is directed to the use of device class entitlements suchthat multiple entitlement objects can be received in the entitlementblock and is entered from a “yes” on blocks 804 or block 812 or from a“no” on block 832. The media client determines (820) whether the programentitlement block comprises a plurality of entitlement objects. Ifmultiple entitlement objects are not present, the method proceeds toblock 806. If multiple entitlement objects are present, the media clientselects (822) a first entitlement object that has a device class thatmatches the user device and uses (824) the entitlements in the selectedentitlement object to enforce entitlements for the program.

Flowchart 800D is directed to the use of a subscriber overrideindicator. When this option is used, the media client will receive (830)a subscriber override indicator from the network node, such as CC 122.In at least one embodiment, the subscriber override indicator isprovided at the time the user requests a channel. Alternatively thesubscriber override indicator can be provided in a beaconing mechanism.Remaining blocks of this flowchart are entered from block 802. The mediaclient determines (832) whether the user override is active, e.g.,whether the value of the indicator is “True”. If the user override isnot active, the method can proceed to any of block 804, block 810 orblock 820, depending on the embodiment. If the user override is active,the media client sends (834) an override entitlement request to acontent controller node and receives (836) override entitlements. Themedia client uses (838) the override entitlements to enforceentitlements for the program.

FIG. 9 depicts a block diagram of an example network node 900, e.g., CC122, according to an embodiment of the present patent application. Oneor more processors 902 may be operatively coupled to various modulesthat may be implemented in persistent memory 904 for executing suitableprogram instructions 908 or code portions with respect to one or moreprocesses set forth hereinabove for providing program and device classentitlements to client devices. Although only a single set of programinstructions are shown, it will be understood that any number ofprocesses can be instantiated in node 900. Appropriate interfaces (I/F)920-1 to 920-M are operative to effectuate request/response messages toand from client devices, which can include managed devices, such asSTBs, as well as unmanaged devices, such as mobile phones, tablets andlaptops. Likewise, appropriate interfaces 1418-1 to 1418-K to variousnetwork elements and/or nodes (e.g., MM 112, ARG 120, and the like) maybe provided in an example network node implementation.

FIG. 10 depicts an overview of an STB 1000, which is an example of amanaged client device. STB 1000 can include appropriatehardware/software components and subsystems configured for performingany of the device-side processes (either individually or in anycombination thereof) with respect to receiving and enforcing programentitlements and device class entitlements as described herein. One ormore microcontrollers/processors 1002 are provided for the overallcontrol of the STB 1000 and for the execution of various stored programinstructions embodied in a media client 1013 that may be part of amemory subsystem 1011. In another variation, a media client may beprovided as a plug-in or an application within a browser, e.g., an HTML5application executed within a browser. Controller/processor complexreferred to by reference numeral 1002 may also be representative ofother specialty processing modules such as graphic processors, videoprocessors, digital signal processors (DSPs), and the like, operating inassociation with suitable video and audio interfaces (not specificallyshown). Where applicable, appropriate interfaces such as cable TV I/Fmodules 1004 and/or satellite TV I/F modules 1006 involving tuners,demodulators, descramblers, MPEG/H.264/H.265 decoders/demuxes may beincluded for processing and interfacing with TV and other contentsignals received via an HFC cable network 1098 or a satellite network1096. In a TV implementation, example demodulators may include QAMdemodulator 1014 and NTSC/ATSC demodulator 1017. Other I/O or interfacessuch as a display interface 1015, Electronic Program Guide (EPG) 1016,user interface 1020, USB/HDMI ports 1018, Ethernet I/F 1008, andshort-range and wide area wireless connectivity interfaces 1012 are alsoprovided. A hard disk drive (HDD) or DVR system 1010 is provided formass storage of all sorts of program assets such as NV media, TV shows,movie titles, multimedia games, etc. Also included in the subscriber UEdevice 1000 is a suitable power supply block 1022, which may includeAC/DC power conversion to provide power for the device 1000. It shouldbe appreciated that the actual power architecture for the subscriberdevice 1000 may vary by the hardware platform used, e.g., depending uponthe core SoC (System on Chip), memory, analog front-end, analog signalchain components and interfaces used in the specific platform, and thelike. In an embodiment where program and device class entitlements areprovided, STB Logic 624 may also be provided that allows for receipt andprocessing of these specific entitlements.

FIG. 11 depicts a block diagram of an example mobile device or wirelessUE device 1100 including a media client 1113 configured to executecertain aspects under control of processor(s) 1102 according to one ormore embodiments of the present patent application. Appropriatetransceiver (Tx/Rx) circuitry 1104 coupled to one or more antenna units1114 is operative to effectuate radio communications for purposes of thepresent disclosure including, e.g., streaming of media and manifests andcommunication with a network node for channel and override entitlements,etc. in addition to other standard cellular telephony/datacommunications. The ABR client/player 1106 is operative to play outsegments stored in an ABR buffer 1112 and a local cache 1110 isoperative to store content.

As illustrated, the ABR client/player 1106 is provided with a pluralityof ABR client controls 1116 that may be selectively operated by usersfor controlling user experience. Such ABR client controls may compriseaudio controls as well as video controls available with respect to astreaming session and may include Play 1116-A, Skip 1116-B, Fast Forward1116-C, Trick Mode or Trick Play 1116-D, Rewind 1116-E, and Next Channelor Channel Change 1116-E. A persistent memory module 1118 may beprovided for storing appropriate program code or software instructionsthat may be executed by processors 1102 for effectuating outage messageprocessing, display of notifications, ABR client control modulation,etc. in conjunction with other modules of the mobile device 1100.

In the above-description of various embodiments of the presentdisclosure, it is to be understood that the terminology used herein isfor the purpose of describing particular embodiments only and is notintended to be limiting of the invention. Unless otherwise defined, allterms (including technical and scientific terms) used herein have thesame meaning as commonly understood by one of ordinary skill in the artto which this invention belongs. It will be further understood thatterms, such as those defined in commonly used dictionaries, should beinterpreted as having a meaning that is consistent with their meaning inthe context of this specification and the relevant art and may not beinterpreted in an idealized or overly formal sense expressly so definedherein.

At least some example embodiments are described herein with reference toblock diagrams and/or flowchart illustrations of computer-implementedmethods, apparatus (systems and/or devices) and/or computer programproducts. It is understood that a block of the block diagrams and/orflowchart illustrations, and combinations of blocks in the blockdiagrams and/or flowchart illustrations, can be implemented by computerprogram instructions that are performed by one or more computercircuits. Such computer program instructions may be provided to aprocessor circuit of a general purpose computer circuit, special purposecomputer circuit, and/or other programmable data processing circuit toproduce a machine, so that the instructions, which execute via theprocessor of the computer and/or other programmable data processingapparatus, transform and control transistors, values stored in memorylocations, and other hardware components within such circuitry toimplement the functions/acts specified in the block diagrams and/orflowchart block or blocks, and thereby create means (functionality)and/or structure for implementing the functions/acts specified in theblock diagrams and/or flowchart block(s). Additionally, the computerprogram instructions may also be stored in a tangible computer-readablemedium that can direct a computer or other programmable data processingapparatus to function in a particular manner, such that the instructionsstored in the computer-readable medium produce an article of manufactureincluding instructions which implement the functions/acts specified inthe block diagrams and/or flowchart block or blocks.

As alluded to previously, tangible, non-transitory computer-readablemedium may include an electronic, magnetic, optical, electromagnetic, orsemiconductor data storage system, apparatus, or device. More specificexamples of the computer-readable medium would include the following: aportable computer diskette, a random access memory (RAM) circuit, aread-only memory (ROM) circuit, an erasable programmable read-onlymemory (EPROM or Flash memory) circuit, a portable compact discread-only memory (CD-ROM), and a portable digital video disc read-onlymemory (DVD/Blu-ray). The computer program instructions may also beloaded onto or otherwise downloaded to a computer and/or otherprogrammable data processing apparatus to cause a series of operationalsteps to be performed on the computer and/or other programmableapparatus to produce a computer-implemented process. Accordingly,embodiments of the present invention may be embodied in hardware and/orin software (including firmware, resident software, micro-code, etc.)that runs on a processor or controller, which may collectively bereferred to as “circuitry,” “a module” or variants thereof. Further, anexample processing unit may include, by way of illustration, a generalpurpose processor, a special purpose processor, a conventionalprocessor, a digital signal processor (DSP), a plurality ofmicroprocessors, one or more microprocessors in association with a DSPcore, a controller, a microcontroller, Application Specific IntegratedCircuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, anyother type of integrated circuit (IC), and/or a state machine. As can beappreciated, an example processor unit may employ distributed processingin certain embodiments.

Further, in at least some additional or alternative implementations, thefunctions/acts described in the blocks may occur out of the order shownin the flowcharts. For example, two blocks shown in succession may infact be executed substantially concurrently or the blocks may sometimesbe executed in the reverse order, depending upon the functionality/actsinvolved. Moreover, the functionality of a given block of the flowchartsand/or block diagrams may be separated into multiple blocks and/or thefunctionality of two or more blocks of the flowcharts and/or blockdiagrams may be at least partially integrated. Furthermore, althoughsome of the diagrams include arrows on communication paths to show aprimary direction of communication, it is to be understood thatcommunication may occur in the opposite direction relative to thedepicted arrows. Finally, other blocks may be added or inserted betweenthe blocks that are illustrated.

It should therefore be clearly understood that the order or sequence ofthe acts, steps, functions, components or blocks illustrated in any ofthe flowcharts depicted in the drawing Figures of the present disclosuremay be modified, altered, replaced, customized or otherwise rearrangedwithin a particular flowchart, including deletion or omission of aparticular act, step, function, component or block. Moreover, the acts,steps, functions, components or blocks illustrated in a particularflowchart may be inter-mixed or otherwise inter-arranged or rearrangedwith the acts, steps, functions, components or blocks illustrated inanother flowchart in order to effectuate additional variations,modifications and configurations with respect to one or more processesfor purposes of practicing the teachings of the present patentdisclosure.

Although various embodiments have been shown and described in detail,the claims are not limited to any particular embodiment or example. Noneof the above Detailed Description should be read as implying that anyparticular component, element, step, act, or function is essential suchthat it must be included in the scope of the claims. Reference to anelement in the singular is not intended to mean “one and only one”unless explicitly so stated, but rather “one or more.” All structuraland functional equivalents to the elements of the above-describedembodiments that are known to those of ordinary skill in the art areexpressly incorporated herein by reference and are intended to beencompassed by the present claims. Accordingly, those skilled in the artwill recognize that the exemplary embodiments described herein can bepracticed with various modifications and alterations within the spiritand scope of the claims appended below.

What is claimed is:
 1. A method operable on a media platform forproviding program entitlements in a broadcast stream, the methodcomprising: identifying a program within a received media stream for achannel; receiving entitlements associated with the program; and writingan entitlement block containing the entitlements into a manifest filefor delivery to a media client in the broadcast stream.
 2. The method asrecited in claim 1 wherein the entitlement block is encrypted and themanifest is cryptographically signed.
 3. The method as recited in claim2 wherein writing the entitlement block comprises writing a plurality ofentitlement objects into the entitlement block, at least one of theplurality of entitlement objects targeting a respective device class. 4.The method as recited in claim 3 further comprising: receivingentitlements associated with the channel; and providing the entitlementsassociated with the channel to a media client responsive to receiving arequest for the channel.
 5. The method as recited in claim 4 furthercomprising providing the media client with a subscriber overrideindicator, wherein one value of the subscriber override indicatorinstructs the media client to ignore other entitlements and requestoverride entitlements for each program.
 6. The method as recited inclaim 5 further comprising determining whether an override entitlementrequest has been received from the media client.
 7. The method asrecited in claim 6, further comprising responsive to determining thatthe override entitlement request has been received, providing the mediaclient with override entitlements that are specific to a subscriber andthe program.
 8. A method operable on a media platform for providingprogram entitlements in a broadcast stream, the method comprising:receiving channel entitlements for a channel in the broadcast stream;receiving program entitlements for a program provided on the channel;providing the channel entitlements to a media client responsive to arequest for the channel; and providing the program entitlements to themedia client prior to showing the program on the channel.
 9. The methodas recited in claim 8 wherein the channel entitlements and the programentitlements are encrypted.
 10. The method as recited in claim 9 whereinthe program entitlements are provided to the media client in programinformation in a manifest file that is cryptographically signed.
 11. Themethod as recited in claim 10 wherein providing the program entitlementscomprises providing a plurality of entitlement objects in the programentitlements, at least one entitlement object of the plurality ofentitlement objects targeting a respective device class.
 12. The methodas recited in claim 11 further comprising providing the media clientwith a subscriber override indicator, wherein one value of thesubscriber override indicator instructs the media client to ignore otherentitlements and request override entitlements for each program.
 13. Themethod as recited in claim 12 further comprising determining whether anoverride entitlement request has been received from the media client,the override entitlement request identifying the program.
 14. The methodas recited in claim 13, further comprising, responsive to receiving theoverride entitlement request, providing the media client with overrideentitlements that are specific to a subscriber and the program.
 15. Anapparatus for providing program entitlements in a broadcast stream,comprising: one or more processors operably coupled to a memory having asequence of program instructions which, when executed by the one or moreprocessors, perform the following: identifying a program within areceived media stream for a channel; receiving entitlements associatedwith the program; and writing an entitlement block containing theentitlements into a manifest file for delivery to a media client in thebroadcast stream of the channel.
 16. The apparatus as recited in claim15 wherein the entitlement block is encrypted.
 17. The apparatus asrecited in claim 16 wherein writing the entitlement block compriseswriting a plurality of entitlement objects into the entitlements block,at least one of the plurality of entitlement objects targeting arespective device class.
 18. The apparatus as recited in claim 17wherein the sequence of program instructions further performs thefollowing: receiving entitlements associated with the channel; andproviding the entitlements associated with the channel to a media clientresponsive to receiving a request for the channel.
 19. The apparatus asrecited in claim 18 wherein the sequence of program instructions furtherperforms the following: providing the media client with a subscriberoverride indicator, wherein one value of the subscriber overrideindicator instructs the media client to ignore other entitlement blocksand request an override entitlement block for each program.
 20. Theapparatus as recited in claim 19 wherein the sequence of programinstructions further performs the following: determining whether anoverride entitlement request has been received from the media client;and responsive to determining that the override entitlement request hasbeen received, providing the media client with an override entitlementblock that is specific to a subscriber and the program.